Zielony status pipeline’u potrafi uspokajać. Problem zaczyna się wtedy, gdy traktujemy go jak jednoznaczny dowód jakości zmiany. Pipeline może zakończyć się sukcesem, mimo że nie sprawdził najważniejszych obszarów ryzyka, uruchomił niewłaściwy zestaw testów albo zaakceptował wyniki, którym zespół nie powinien ufać.

Podczas prelekcji pokażę, jak spojrzeć na quality gates nie jako na techniczny warunek „pass/fail”, ale jako na mechanizm wspierający decyzję o tym, czy zmiana jest wystarczająco bezpieczna, aby przejść dalej.

Przyjrzymy się sygnałom, które możemy wykorzystać przy budowaniu takich bramek: wynikom testów jednostkowych, API i UI, analizie statycznej, lintingowi, type checkingowi, pokryciu kodu, testom dostępności, stabilności testów, raportom i artefaktom z pipeline’u oraz danym historycznym. Zastanowimy się również, które z tych informacji rzeczywiście powinny blokować dalszy proces, a które lepiej traktować jako ostrzeżenie albo sygnał wymagający dodatkowej analizy.

Szczególną uwagę poświęcę wiarygodności danych, na których opieramy decyzję. Flaky tests, automatyczne retry, arbitralne progi coverage czy duża liczba testów bez jasno określonego celu potrafią sprawić, że pipeline wygląda zdrowo, chociaż poziom ryzyka pozostaje wysoki. Z drugiej strony zbyt restrykcyjne bramki mogą zatrzymywać wartościowe zmiany z powodów, które nie mają realnego wpływu na jakość produktu.

Pokażę również, dlaczego jeden zestaw reguł nie powinien być stosowany do każdej zmiany. Innego poziomu pewności potrzebujemy dla standardowego pull requesta, innego przed wdrożeniem release candidate, a jeszcze innego dla hotfixa, migracji danych czy zmiany infrastrukturalnej. Dobry quality gate powinien uwzględniać kontekst, zakres oraz potencjalne konsekwencje zmiany.

Prelekcja będzie miała charakter techniczno-praktyczny, ale nie będzie instrukcją konfiguracji jednego konkretnego systemu CI. Zamiast tego przedstawię sposób projektowania bramek jakości, który można zastosować niezależnie od wykorzystywanego narzędzia: jak dobierać sygnały, jak określać ich znaczenie, kiedy blokować proces, jak obsługiwać wyjątki oraz jak nie doprowadzić do sytuacji, w której zespół przestaje ufać własnemu pipeline’owi.

Najważniejsze pytanie nie będzie więc brzmiało:

„Czy wszystkie joby są zielone?”

ale:

„Czy mamy wystarczająco dużo wiarygodnych informacji, aby świadomie zaakceptować ryzyko tej zmiany?”

Taki sposób myślenia pozwala traktować CI nie tylko jako miejsce wykonywania testów, ale jako element procesu podejmowania decyzji o jakości i bezpieczeństwie kolejnych zmian.